-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rcc: Add peripheral reset and control #12
Conversation
Hello, how can I help in this? |
Hey @joaomorenorf! So I based this on top of the definitions I added to the stm32-rs repo to flesh out the peripheral definitions for the H503 (I mostly tried to include definitions for the H573 and H562/3 where they didn't significantly diverge from from the H503, but unfortunately the RCC was one case where it did). You could make a PR into repo to add the definitions for the RCC for the STM32H573 (and STM32H562/3), as they share the same RCC definitions). You can see what I've done with H503 here:
As I noted in a few of those files, the H573 is mostly a superset of the H503 in terms of functionality, so it should just be necessary to add the missing register definitions. That all said... it took a while for my PRs to get merged into the I can take a look at whether I can adapt what I have here easily, but I won't likely be able to get to it for the next week or so. Otherwise, if you wanted to take a stab at one or the other approach, that would be awesome, and I would be very happy to give you pointers, review etc. |
@joaomorenorf So I took another look at what was breaking the build, and realized that the main breakage was just that the clock source variants that let you easily select which clock to use for which peripheral are only defined for the H503. I reworked the macro in There's one caveat: this means that to use one of these peripherals there would be the minor inconvenience of using the PAC directly to configure the clock source when a non-default clock is used for a peripheral, and when instantiating a peripheral driver such as I2C, you'd need to provide a dummy implementation of the ResetEnable trait (this will become more apparent as I merge these drivers in, but it's a pretty minor inconvenience, IMO) and everything should be otherwise quite useable. I would still recommend making a PR into the |
b39438f
to
9375aa5
Compare
1b4f094
to
521d77e
Compare
@joaomorenorf On another note, I'll try to make sure that the code compiles for all variants (and keep them enabled in CI!), but I haven't tested anything on those variants, and there is a bunch of functionality that I haven't implemented (both for other MCUs in the family and in general). As an example in the RCC module, PLL3 for the H573 looks like it has a subset of the functionality of the other 2 PLLs, so we'd need to account for that before we can enable that PLL here. As for how you could help further, testing the code on those MCUs would be super helpful, and your contributions to this repo for missing functionality would be very welcome too. I've still got a bunch of modules still to merge (e.g. serial, gpio, spi, i2c, icache), but there's a lot more that needs to be implemented, so there's plenty of scope to help. |
Thank you, @astapleton, Now I'll focus on adding the registers definitions to |
521d77e
to
89ba261
Compare
Adds helper functions for enabling, resetting and disabling peripherals via the RCC control interface. Note: This also disables builds for the STM32H56/7x processors as the STM32H5 PAC crate does not provide the necessary definitions for the RCC at this time.
Adds helper functions for enabling, resetting and disabling peripherals via the RCC control interface.
Note: This also disables builds for the STM32H56/7x processors as the STM32H5 PAC crate does not provide the necessary definitions for the RCC at this time.